SGI Developer Toolbox 6.1

home *** CD-ROM | disk | FTP | other *** search

/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 1.iso / toolbox / FAQs / SGIfaqs / Indy-faq < prev next >

Wrap

Text File | 1996-11-11 | 33.3 KB | 977 lines

startings of an Indy FAQ While not exactly a list of *Frequently* asked questions, this file does contain question-and-answer messages saved out from internal and external newsgroups including comp.sys.sgi.graphics/comp.graphics.opengl/ comp.sys.sgi.apps/comp.sys.sgi.misc/comp.sys.sgi/sgi.engr.all/sgi.engr.dev, which are felt to contain potentially useful-to-developers information. # 1. Is there any way to increase lrectwrite performance on the Indy? # 2. How can I test my app, developed on a 24-bit system, on an simulated 8-bit-looking monitor, to see what it looks like there? # 3. The mapping of colours from 24 bit RGB value to 12 bit RGB values is different on the Indy compared to Express graphics. # 4. Indy clean install of 5.1 non-IndigoMagic has major error--is it serious? # 5. How come my 'objectserver' always dies? # 6. vfork and fork clarification # 7. how can I force a system dump to analyze where the machine is clogging up? # 8. Indy Devstation C++ software query # 9. Z-buffer on an Indy? #10. will IndigoMagic desktop background accept *other* background programs? #11. disabling starting up IndigoMagic background with icons #12. any way to disable IndigoMagic placing touched files from my home directory on the desktop? #13. Indy Video Out Options #14. IndyCam Frame Rate and Real Time DSP #15. Indy v. Indigo Speed? #16. MIDI out on indy? #17. Does the indy have a floppy? #18. FIB 354: IndigoMagic "Can't contact objectserver" message #19. Need Indy video input library info #20. An avid mac user into MIDI looking at buying indy #21. clogin not acting like old pandora in 5.1.1 # 1. Is there any way to increase lrectwrite performance on the Indy? ------------------------------------------------------------- On Indy and XL systems, lrectwrite performance can be significantly increased for some applications by locking the data buffer in memory and making the buffer uncacheable. This is worth doing if the same buffer is to be used in repeated calls to lrectwrite. See mmap(2), mpin(2), cachectl(2), and cacheflush(2). Note: it may be dangerous to use this technique with lrectread and sproc. If two processes are sharing memory address space, and one of them starts a dma into memory which the other thread unmaps while the dma is running, system memory could be corrupted. # 2. How can I test my app, developed on a 24-bit system, on an simulated 8-bit-looking monitor, to see what it looks like there? ------------------------------------------------------------- We have provided a binary utility in ~4Dgifts/toolbox/bin called setfb which is intended for use by developers wishing to test their applications in an 8-bit system, when what they have is a 24-bit system. setfb sets the effective frame buffer depth to 8 or 24 bitplanes. Actually what this does is program the xmap9 chips to use 8 or 24 bits of pixel data from the frame buffer. The graphics driver will remember what the depth is set to, and report this value when queried by GL, Xsgi, or other applications. The depth set by setfb will remain in effect until the system is rebooted, or setfb is run with a new depth. USAGE: setfb -d depth If depth is not one of 0,8,24, a usage message is printed. Depth = 0 tells the driver to set depth to the actual number of bitplanes installed. NOTE: only useable with Indigo^2 XL and Indy machines. BUGS: no multi-head support; affects all installed NG1 boards. # 3. The mapping of colours from 24 bit RGB value to 12 bit RGB values is different on the Indy compared to Express graphics. ------------------------------------------------------------- The mapping of colours from 24 bit RGB value to 12 bit RGB values is different on the Indy compared to Express graphics. Indeed, all the 8 bit to n bit (where n<8) conversions, including dithering, have been changed. The following is table of 8 bit colour components written to a double buffered 12 bit frame store compared with the values actually placed in the framestore: 8 Bit Component Written 4 Bit component in framestore ----------------------- ------------------------------ Indy 24 bit or XL XS24/XZ/Elan/Extreme ----------------- -------------------- 0x00 - 0x07 0x00 - 0x0f 0x00 0x08 - 0x18 0x10 - 0x1f 0x10 0x19 - 0x29 0x20 - 0x2f 0x20 0x2a - 0x3a 0x30 - 0x3f 0x30 0x3b - 0x4b 0x40 - 0x4f 0x40 0x4c - 0x5c 0x50 - 0x5f 0x50 0x5d - 0x6d 0x60 - 0x6f 0x60 0x6e - 0x7e 0x70 - 0x7f 0x70 0x7f - 0x90 0x80 - 0x8f 0x80 0x91 - 0xa1 0x90 - 0x9f 0x90 0xa2 - 0xb2 0xa0 - 0xaf 0xa0 0xb3 - 0xc3 0xb0 - 0xbf 0xb0 0xc4 - 0xd4 0xc0 - 0xcf 0xc0 0xd5 - 0xe5 0xd0 - 0xdf 0xd0 0xe6 - 0xf6 0xe0 - 0xef 0xe0 0xf7 - 0xff 0xf0 - 0xff 0xf0 This mapping of colours has upset a morphing package which uses RGBwritemask to provide double-buffered overlay planes. The package uses the top bit of each colour component as the overlay plane, leaving 3 bits for each of R, G and B. On Express graphics the components are simply truncated - on the Indy they have now implemented a new colour mapping algorithm (see the table above). >> has someone seen this ugly behaviour before? I have a small >> gl program that (in its stripped form) just opens a (old-style) >> gl-window (doublebuffered, RGB, zbuffer true) and clears the >> background to some greyish color (60/60/60). On a Extreme, XZ >> and Elan the window looks good. On a 24bit Indy or Indigo2/XL >> you can see really bad dither patterns. How can this be? All >> systems have 24 bitplanes and use 12 of them in db-mode. Some >> kind of dithering has to happen on all of them. Why is the >> dithering for the newport GFX different and, worse, really bad? >> Is there a way to influence the used dither patterns? Unfortunately >> this effect is very visible at my favourite application site. >> Using "dither(0)" solves the problem for the background, but >> shaded images look really funny afterwards. > Yes, I ran into this a few months ago. The way colour values are computed, > when there are less than 8 bits per component, has changed. You have just > run into a case where the values computed are different on Newport > graphics compared to Express. This is merely the choice of colors. As explained above, the color values are dithered differently. Indy uses a dithering technique that keeps color ramps linear, rather than maxing out at colors > 0xf0. Note that the dither patterns are no worse than on an elan, just that the different color values come out with the solid patterns, and different ones come out with the 'dotty' dither patterns. Again, see the explanation above. >> In this particular package some grey colours on Express graphics were >> becoming bright magenta on the Indy! To work around the problem the >> developer has simply truncated the RGB values to 4 bits. Only on 8 bit machines does gray get dithered with green-magenta colors (due to the fact there aren't the same number of bits for R, G and B, you get either 1-2-1 or 3-3-2 bits). On a 24 bit Indy or XL, grays are only dithered with shades of gray. >> Has anyone else noticed any similar problems which could have been caused >> by this? Could it give us problems with any other packages? Should we ask >> for a gl_compat facility to ensure compatibility for old 4.0.5 >> applications? Unless you want to ask for dead-slow graphics (software would have to render down to each individual pixel), there's no switch to use. The dithering is implemented in the REX3 hardware. # 4. Indy clean install of 5.1 non-IndigoMagic has major error--is it serious? ------------------------------------------------------------- > Subject: Indy clean install of 5.1 non-IndigoMagic has major error > > O.K., I know I wasn't supposed to install non-IndigoMagic on an Indy but > never mind, I have some lame excuses. > > After doing a clean install I get this error when booting from ttyd1. > > --------------------------------------------------------------------------- > Starting up the system... > > IRIX Release 5.1 IP22 Version 08280056 System V > Copyright 1987-1993 Silicon Graphics, Inc. > All Rights Reserved. > > The system is coming up. > > root: *** IRIS's Internet address is the default > root: *** Using standalone network mode. > UX:touch: ERROR: Cannot create /var/tmp/.swap.virtual: No such file or directory > swap:swapadd failed for /var/tmp/.swap.virtual: No such file or directory > The system is ready. > --------------------------------------------------------------------------- > > So is this serious ? No, it's not serious. The reference to /usr/tmp/.swap.virtual was a hack so that applications would not die on a 16 Mb. Indy due to running out of virtual swap. # 5. How come my 'objecever' always dies? ------------------------------------------------------------- Subject: Re: How come my 'objectserver' always dies? > Subject: How come my 'objectserver' always dies? > > I've installed 5.1 MR/IndigoMagic on the machines in my office. The > Indy consistently complains about: > > Sep 15 15:27:57 3D:sarcasm objectserver[523]: base verify: get error for 59.101.1762080780.10 > Sep 15 15:27:59 3D:sarcasm objectserver[523]: local account: error creating user > Sep 15 15:27:59 3D:sarcasm objectserver[523]: NIS account: error creating user > > My PI also complains but doesn't mention the 'base verify' error. > > Has anyone seen and solved this problem? Paps I'm better off > without the objectserver? > Your not missing much. I had problems with my object server as well, but it was fixed when I did this as root : > /etc/init.d/cadmin stop > rm -rf /var/Cadmin/data > /usr/Cadmin/bin/parseclasses > /etc/init.d/cadmin start > _____________________________________________________ The above 4 lines is equivalent to saying : /etc/init.d/cadmin clean _____________________________________________________ | The above 4 lines is equivalent to saying : | /etc/init.d/cadmin clean We just installed 5.1.1 on our Indy in the lab, and we had problems with the object server. When I did a "/etc/init.d/cadmin clean", it did not fix the problem. However, when I did: /etc/init.d/cadmin stop rm -rf /var/Cadmin/data /usr/Cadmin/bin/parseclasses /etc/init.d/cadmin start the problem went away. So.... either "/etc/init.d/cadmin clean" doesn't do what you said it should do, or it's a bug. _____________________________________________________ > So.... either "/etc/init.d/cadmin clean" doesn't do what you said > it should do, or it's a bug. But then I did forget a step. Doing a clean does everything but restart the objectserver. Sorry about that ... what you want is this : /etc/init.d/cadmin clean /etc/init.d/cadmin start # 6. vfork and fork clarification ------------------------------------------------------------- Newsgroups: sgi.engr.devp From: olson@anchor (Dave Olson) Subject: Re: Indy clean install of 5.1 non-IndigoMagic has major error Date: Fri, 17 Sep 93 03:27:51 GMT | One other source of this problem is with tasks that fork. I think | everytime a task forks it makes a virtual memory copy of itself even | though it may not use very little of the virtual memory. If a big | task forks once or twice the virtual memory is gone and things start | crashing. | | This is why vfork was around at one time on IRIX and is still around on | other UNIX systems. vfork didn't duplicate all the virtual memory up | front as I remember. In 4.0.5 IRIX made fork and vfork synonymous since | we didn't have strict accounting. It didn't matter how much virtual | space you wasted on a fork. Now that strict accounting is back we | need vfork back. No, we made vfork and fork the same because vfork *emulation* via sproc really didn't work right, and we decided it was best to just stop supporting it than to continue hacking trying to make it work. Even the original creators of vfork stated up front that it was a gross hack. # 7. how can I force a system dump to analyze where the machine is clogging up? ------------------------------------------------------------- > Subject: force indy dump > > Hi all, > > One developer up in the booneys (i.e., a long way out of town) has reported > that every so often their Indy freezes, and they can't get any useful info > on why it is happening (running 5.1 MR, but REX3 rev A with appropriate > library). Is there some way I can force a system dump so that I can analyse > where the machine is clagging up ? You can try to run a debugging kernel !! That way you can drop into the kernel debugger and pinpoint exactly where the problem is. Well maybe ! You need a terminal (or at least a wire connected between the serial ports of the Indy and another machine then change the file /usr/var/sysgen/system/irix.sm in the following : ---- EXCLUDE: idbg ---- becomes INCLUDE: idbg ---- The lines commented (at the end of the file) starting with *CCOPTS: and *LDOPTS: should be uncommented and the uncommented ones should be commented ! (In other words choose the appropriate version of CCOPTS and LDOPTS !) Then autoconfig and reboot. When the kernel hangs strike ^A at the terminal and single step until you find out where it hangs ! # 8. Indy Devstation C++ software query ------------------------------------------------------------- Article: 1674 of comp.sys.sgi.apps From: pal@xanadu.wpd.sgi.com (Anil Pal) Subject: Re: Indy Devstation software Organization: Silicon Graphics, Inc. Date: Thu, 30 Sep 1993 00:00:52 GMT In article <CE4F28.LyE@ssesco.com>, mitchv@ssesco.com (Mitch Voehl) writes: |> I have heard about the Indy Devstation hardware and software package. |> |> 1. What version of C++ is available on the Devstation? |> |> 2. Is this an SGI written C++ compiler, or will it still be |> the cfront based compiler? The DevStation includes an Indy workstation with 16M RAM and 340M disk, the Iris Development Option, and the CaseVision/WorkShop programming tools. The base price ($5995 as described above) does not include a C++ compiler. You can purchase (at the usual price) the regular SGI C++ compiler package for the DevStation (or for any other SGI workstation). This is currently based on cfront 3.x. SGI has announced WorkShop/Pro C++, to be released in December, which will include a native compiler (not based on cfront, but source-code compatible with cfront 3.0). |> 3. Will it contain exception-handling? No, this is C++ 3.0-level, so does not contain exception handling. -- Anil A. Pal pal@sgi.com (415)-390-5279 # 9. Z-buffer on an Indy? ------------------------------------------------------------- Article: 4954 of comp.sys.sgi.misc From: rc@sgi.com (Roger Corron) Subject: Re: Indy vs. Indigo 4000 Date: 28 Sep 1993 18:33:09 GMT Organization: Silicon Graphics Inc., Mountain View, CA Lines: 14 Terran Boylan (boylan@kodiak.eai.iastate.edu) wrote: : I've heard different versions of whether the Indy has a Z-buffer or not. : Does it? Will an application executable (that uses the Z-buffer) : that was compiled (with -lgl_s, etc.) under 4.05XYZ run on an Indy under : 5.1.1 with its Z-buffer functionality intact? Yes. The Z buffer is implemented in software and is kept in virtual memory, as with Indigo Entry systems. Roger Corron Silicon Graphics rc@sgi.com #10. will IndigoMagic desktop background accept *other* background programs? ------------------------------------------------------------- Article: 19517 of sgi.engr.all From: dave@sgi.com (dave "who can do? ratmandu!" ratcliffe) Subject: Re: Momma...give me back my background! Organization: Silicon Graphics, Inc. Date: Tue, 5 Oct 1993 15:30:33 GMT Lines: 25 >If you want icons on the background, you have to >stick with the backgrounds we've got. i'm a real info-dummy w/regard to the indigomagic-universe. i've seen indys with these new backgrounds and was wondering what one wud do to make one's bitch bgpaste'd collage of rgb imgs show up. since you stepped up to the plate, how about answering this one? Q: Is it true that one can either have their previous background OR the IndigoMagic desktop background replete with icons, but not both? Follow-On: If the above is true, will this always be the way things are, or is SGI intending to enhance IndigoMagic so one can still have one's own background image[ collage]/program AND ALSO have the full-functionality of the desktop including icons? Article: 19557 of sgi.engr.all Subject: Re: Momma...give me back my background! Date: Wed, 6 Oct 93 20:16:03 GMT >Q: Is it true that one can either have their previous background OR > the IndigoMagic desktop background replete with icons, but not both? Yes this is true. This is not what we wanted, but it was necessary to get icons on the background (a marketing and management requirement) with decent performance (we looked at using the X shape extension but the performance with a large number of icons was unacceptable--please direct all energy spent on flames stating that the current performance is unacceptable into some productive work on improving it). > Follow-On: If the above is true, will this always be the way things > are, or is SGI intending to enhance IndigoMagic so one > can still have one's own background image[ collage]/program > AND ALSO have the full-functionality of the desktop > including icons? I wont make any statements regarding perpetuity, but we are not actively working to enhance the capabilities. If someone could point me at some easy to use efficient code to convert files in image formats into X pixmaps, I'll try to get it in. But don't count on dynamic or GL backgrounds unless we can get significant improvement on the shape extension performance. Article 19627 (6 more) in sgi.engr.all: Subject: Re: Momma...give me back my background! Organization: Silicon Graphics, Inc. Mountain View, CA Date: Mon, 11 Oct 93 17:02:36 GMT We tried using the shape extension. Once we had more than about 10 icons on the background, things started to slow down. With about 20, it became unusable. (The main thing that slowed down was moving windows, particularly for drag and drop.) While we were able to perform some tricks to help improve things, we never achieved an acceptable performance. Regarding overlapping icons, that we can deal with although its a big tricky. #11. disabling starting up IndigoMagic background with icons ------------------------------------------------------------- Article: 19660 of sgi.engr.all Subject: Re: Momma...give me back my background! Organization: Silicon Graphics, Inc., Mountain View, CA Date: Tue, 12 Oct 93 21:35:24 GMT In order to support icons on the background it was necessary to make a fake background window. If you want to disable starting up with icons on the background, create a file called ~/.desktop/nodesktop. The next time you start up it will be without icons on the background and you will be able to set your own backgrounds. #12. any way to disable IndigoMagic placing touched files from my home directory on the desktop? ------------------------------------------------------------- Article 19702 (32 more) in sgi.engr.all: Subject: Re: Momma...give me back my background! Organization: Silicon Graphics, Inc. Mountain View, CA Date: Thu, 14 Oct 93 16:47:33 GMT > Is there any way to keep the desktop, but prevent it from > placing any files you touch in your home directory on the desktop? There is currently no way to turn this off, although I agree there should be. I've forwarded your posting to our group. #13. Indy Video Out Options ------------------------------------------------------------- Article: 2453 of comp.sys.sgi.graphics From: msc@ramoth.esd.sgi.com (Mark Callow) Subject: Re: Indy Video Out Options Organization: Silicon Graphics, Inc. Mountain View, CA Date: Tue, 12 Oct 93 18:04:10 GMT In article <1993Sep22.154608.1660@ncar.ucar.edu>, bill@rap.ucar.edu writes: > I am interested in producing NTSC output from software run on an Indy. > Can anyone tell me what video-out graphics board options are available? > Note that the output is destined for broadcast, so if some better > quality output were available, we would probably be interested in > hearing about that in particular. There will be a product, currently and confusingly named Indy Video, (also known as Galileo Junior) designed for video out on the Indy. It is, as the latter name implies, a stripped down version of Galileo video. This is as much as I know about it. #14. IndyCam Frame Rate and Real Time DSP ------------------------------------------------------------- Article: 2456 of comp.sys.sgi.graphics From: msc@ramoth.esd.sgi.com (Mark Callow) Subject: Re: IndyCam Frame Rate and Real Time DSP Organization: Silicon Graphics, Inc. Mountain View, CA Date: Tue, 12 Oct 93 18:48:37 GMT Lines: 24 In article <C92HK.93Oct9230359@msc4.comlab>, c92hk@comlab writes: > > Greetings, > can somebody please fill me in on the frame rate and resolution of the > IndyCam ? Can I do any reasonable image processing of the frames in real > time (like smoothing,edge detection etc.) ? I only need e.g. 200x300 4bit > gray images, but need to do real time tracking (crude). > It is possible to capture 30 frames/sec of full resolution NTSC or PAL frames into the Indy's main memory through the VINO board. The IndyCam delivers 30fps to the VINO's SGI-D1 input. The IndyCam resolution is roughly half of NTSC (approx 320 x 240). I can't remember the exact numbers. There is time and cpu cycles left over after capturing to do some simple image processing. In our InPerson software we capture and compress 15 frames a second (at 320x240) using about 50% of the cpu. In our application we want to leave cpu cycles for audio, drawing on the whiteboard and whatever else the user wants to do. #15. Indy v. Indigo Speed? ------------------------------------------------------------- Newsgroups: comp.sys.sgi.misc From: msc@ramoth.esd.sgi.com (Mark Callow) Subject: Re: Indy v. Indigo Speed? Organization: Silicon Graphics, Inc. Mountain View, CA Date: Tue, 12 Oct 93 20:04:32 GMT In article <291kit$fdo@sol.ctr.columbia.edu>, shenkin@still3.chem.columbia.edu writes: > In article <kt7d6je@zuni.esd.sgi.com> > olson@anchor.esd.sgi.com (Dave Olson) writes: > > >...If all your rendering is done completely on the CPU, an > >SC Indy and an r4k Indigo will be *very* similar in performance. > > Maybe. The only Indigo that does all its rendering on the CPU is > the one with "entry-level graphics," which only operates at > low-resolution. An Indy will usually have a high-resolution > display. Thus, since the CPU's run at virtually the same rate, > wouldn't the Indigo render faster? > No. The Indigo does all its transformations and some rasterization on the CPU. Most of the rasterization step (lines, pixel fills, plane operations etc) is done in hardware. This is the step that takes longer on a screen with more bits. Indy Graphics is faster than Indigo Entry Graphics so for graphics an Indy is a bit faster than an Indigo R4K Entry Graphics. But Dave's statement is correct. When rendering entirely on the CPU the two machine are very similar. Rendering entirely in software on the CPU is done by many software packages when photo-realistic images are needed. Often the result is never seen until imaged onto film. #16. MIDI out on indy? ------------------------------------------------------------- Newsgroups: comp.sys.sgi.misc From: archer@elysium.esd.sgi.com (Archer Sully) Subject: Re: MIDI out on indy? Organization: Silicon Graphics, Inc. Mountain View, CA Date: Thu, 14 Oct 93 17:54:50 GMT In <brownc.750602106@p4.cs.man.ac.uk> brownc@p4.cs.man.ac.uk (Christopher C. Brown) writes: ; I am involved in some research using midi to control a synth. ; I am using an indy to write the software, and need to connect ; it to the synth. Does anyone have any information on whether ; the indy's serial port is compatible with midi or if I need to ; buy/build an interface unit of some kind. I'm using Tom ; Benoist's Midi toolkit to send midi messages. The Indy can do MIDI (but it was a struggle!). The Indy serial port can use a simple Macintosh MIDI adapter (eg Opcode MIDI Translator, Anatek Pocket Mac, and similar devices). There is also a MIDI library that I wrote which runs on Indy, as well as a driver. Information about these facilities can be found in the Digital Media programming guide, which should come with the Digital Media developers option (see your local sales critter for more info). I'm not familiar with Tom's package, so I don't know if it can be adapted to work with the MIDI library or not. If you send me a pointer to it I can take a look at it and let you know. If it can't, you will also need some code to set up the serial port, which I'll be happy to provide. #17. Does the indy have a floppy? ------------------------------------------------------------- Newsgroups: comp.sys.sgi.graphics From: olson@anchor.esd.sgi.com (Dave Olson) Subject: Re: Does the indy have a floppy? Organization: Silicon Graphics, Inc. Mountain View, CA Date: Mon, 18 Oct 93 08:08:50 GMT Lines: 12 In <29k1kl$19q@indigo.imp.ch> ilg@imp.ch (Philippe Steindl) writes: | The title says it all :) Does it have a HD (1.44) or hiher (2.88) floppy? | BTW: is there any kind of extension bus in the indy? You can get an optional floptical, which handles 720K and 1.44 MB floppies also (but I don't think it handles 2.88 MB). #18. FIB 354: IndigoMagic "Can't contact objectserver" message ------------------------------------------------------------- Newsgroups: sgi.engr.all Subject: Re: objectserver doesn't work on my machine Organization: Silicon Graphics, Inc. Date: Tue, 19 Oct 1993 15:53:32 GMT |> Before I file a bug on this I want to perform a reality check. Ever |> since I have installed 5.1 on my machine (krill.corp), objectserver |> wont run correctly. It appears to run but never forks and therefore |> never responds to anything. I've tried running in it in debug mode, |> cleaning the database, etc. with no success. Needless to say, I have |> been unable to play with the new IndigoMagic environment completely |> since alot of programs won't run. Here is FIB 354 -- Might make sure you have tried all of this: *************************************************************************** CUSTOMER SERVICES ENGINEERING FIELD INFORMATION BULLETIN ******************************************************************************** This FIB has been revised. The * denotes where changes have been made to the orginal document. FIB 354 TITLE IdigoMagic "Can't contact objectserver" message MODELS AFFECTED Systems running the IngidoMagic User Environment SOFTWARE RELEASE IRIX 5.1 and greater PARTS/DOCUMENTATION AFFECTED PART NUMBER REV DA REPORTED BY Anne Eagle DATE REPORTED Oct 7, 1993 ASSIGNED TO Anne Eagle DATE RESOLVED Oct 7, 1993 EFFECTIVITY Immediate REFERENCE *objectserver(1M) man page, IRIX 5.1 Release Notes - desktop_eoe chapter, Personal System Administration Guide (Insight) DESCRIPTION *After logging in, several systems are getting a dialog box with the message: "FM: Can't contact objectserver" ACTION REQUIRED None...For your information only! RESOLUTION/RECOMMENDATION The objectserver is a daemon that maintains the state of the IndigoMagic User Environment's objects. Examples of objects include user accounts, file systems and peripheral devices such as DAT's and CD-ROMS. The objects are defined in the /usr/Cadmin/classes directory. For more information, check the objectserver(1M) man page as well as the chapter on desktop_eoe in the IRIX 5.1 Release Notes. There is also troubleshooting information on the objectserver and directoryserver in the Personal System Administration Guide in Insight. f you are getting the "Can't contact objectserver" message, log into the system as root, and do the following: into the system as root, and do the following: -------------------------------------------- Make sure that the objectservers are running -------------------------------------------- In a shell window, type: # ps -ef | grep objectserver You should see three lines whose last columns show: /usr/Cadmin/bin/objectserver /usr/Cadmin/bin/objectserver grep objectserver If you see none or only one occurrence of the objectserver ---------------------------------------------------------- Check to see if the objectserver configuration flag is on: In a shell window, type: # chkconfig | grep objectserver You should see the line: objectserver on If objectserver is "off", you need to turn it on by typing: # chkconfig objectserver on Then cycle the cadmin init script: # /etc/init.d/cadmin stop # /etc/init.d/cadmin start Now do the "ps" again and make sure that the objectservers are running. (Give them a few seconds to start up before doing the ps.) If they are both running at this point, the error message should no longer appear. If it still does, go on to the next step. * If you see two objectservers running ------------------------------------- In this case, the correct number of objectservers are running; if you are getting the message "Can't contact objectserver", then the object database may have gotten corrupted. Stop the objectservers, clean up the database and start the objectservers again by typing: # /etc/init.d/cadmin stop # /etc/init.d/cadmin clean # /etc/init.d/cadmin start #19. Need Indy video input library info ------------------------------------------------------------- Newsgroups: comp.sys.sgi.misc From: spencer@hailwood.asd.sgi.com (Paul Spencer) Subject: Re: Need Indy video input library info Date: 20 Oct 1993 21:23:32 GMT Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 21 mmcohen@dewi.ucsc.edu (Dr. Michael M. Cohen) says: > We have a beta Indy loaner. Can't find anything on library > calls for video input. Hope they exist. We're trying to > get running something that's up on an Indigo with starter video. > [starter video specific code example deleted] The Indy uses the VideoLibrary, a new common API that will work on all future SGI video products. The examples that came with your Indy were written with these. Unfortunately, the API has not been released yet; you cannot write your own software for video input right now. Contact the person who lent you the Indy for availability. #20. An avid mac user into MIDI looking at buying indy ------------------------------------------------------------- Newsgroups: comp.sys.sgi.misc From: gints@prophet.esd.sgi.com (Gints Klimanis) Subject: Re: An avid mac user looking at buying indy Organization: Silicon Graphics, Inc. Date: Sat, 23 Oct 93 07:30:47 GMT Lines: 47 In article <1993Oct23.020608.20300@iitmax.iit.edu>, demonmn@iitmax.iit.edu (Narayan Nayar) writes: |> I am an avid mac user, with a pretty decent setup (as far as macs |> go). I've seen and heard a little about the Indy and it has caught |> my interest. I am looking to purchase one, but have a few concerns... |> |> I primarily do multimedia stuff. I have a large MIDI setup, and use |> my mac to manage that. I've seen one or two posts regarding SGI's |> and MIDI, and it doesn't look too promising, at least as of yet. So far, we have Blue Ribbon shipping SuperJam and Bars&Pipes MIDI applications: Company: Blue Ribbon Sound Works, Ltd. Interest: MIDI sequencer for SGI Indigo FON: (404)315-0212 FAX (404)315-0213 Address: Suite 200 1605 Chantilly Dr. Atlanta, Georgia 30324 |> I also do a lot of image editing and 3d modeling/rendering. I know |> the Indy will be better in that regard. |> |> Basically, I'd like to know how good the mac emulation is on an Indy, |> and will it go so far as to let me emulate programs such as my MIDI |> sequencer? Have not yet heard of Quorom running any Macintosh MIDI applications such as Opcode StudioVision, Passport Master Tracks, etc. |> What type of serial ports does it have (how will I hook up a MIDI |> interface)? You may use any of the following Macintosh MIDI interface boxes to connect to the Indy RS422 ports: Macintosh MIDI boxes for Indigo/Indigo2/Indy/4D30/4D35: For roughly $50 US, Opcode MIDI Translator (replaced by MIDI Translator II) Anatek Pocket Mac #21. clogin not acting like old pandora in 5.1.1 ------------------------------------------------------------- Newsgroups: comp.sys.sgi.misc From: olson@anchor.esd.sgi.com (Dave Olson) Subject: Re: clogin not acting like old pandora in 5.1.1 Organization: Silicon Graphics, Inc. Mountain View, CA Date: Sun, 24 Oct 93 03:56:18 GMT Lines: 10 clogin is the Indigo Magic replacement for pandora; normally it will (currently) be only on Indy's. Yes, with noiconlogin, your changed rgb file won't be displayed, with clogin. It appears to have been done deliberately, but there also seems to be some sentiment for re-enabling the feature.